Conventionally, middleware, which may include one or more programs, is used to operatively couple at least two otherwise separate applications. In other words, the middleware may be analogized to be the “glue” between the two applications. For example, some middleware may operatively couple a database system to a web server to allow users of the web server to access the database system. One type of middleware is referred to as messaging middleware, which is used to route messages between applications. A message as used herein broadly refers to communication between applications.
Messaging is a crucial component for enterprise and high-performance computing, Service Oriented Architecture (SOA) deployments, and platform services. Until recently, enterprise-level messaging systems have mostly been proprietary, mutually incompatible, and quite expensive. Some open messaging systems have existed, but until now, they typically do not offer the reliability or performance needed for demanding applications.
In response to the demands for a predictable, high speed, reliable, secure, and scalable messaging system, the Advanced Messaging Queuing Protocol (AMQP) specification was developed to create an open standard for interoperable messaging. AMQP defines both a wire level protocol for messaging (the transport layer) and higher level semantics for messaging (the functional layer).
Currently, AMQP treats all message content as opaque. The existing AMQP approach has advantages in terms of simplicity and efficiency. However, the use of XML content in messaging is increasing, and the current AMQP lacks support for routing based on XML content. Furthermore, the current interfaces are typically not designed for easy integration of XML messages into standard XML application programming interfaces (APIs).